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ABSTRACT 

This work presents the design and implementation of our 
Browser-based Massively Multiplayer Online Game, Living 
City, a simulation game fully developed at the University 
of Messina. Living City is a persistent and real-time digital 
world, running in the Web browser environment and acces- 
sible from users without any client-side installation. 

Today Massively Multiplayer Online Games attract the 
attention of Computer Scientists both for their architectural 
peculiarity and the close interconnection with the social net- 
work phenomenon. 

We will cover these two aspects paying particular atten- 
tion to some aspects of the project: game balancing (e.g. al- 
gorithms behind time and money balancing); business logic 
(e.g., handling concurrency, cheating avoidance and avail- 
ability) and, finally, social and psychological aspects involved 
in the collaboration of players, analyzing their activities and 
interconnections. 

Categories and Subject Descriptors 

H.5.3 [Information Interfaces And Presentation]: Group 
and Organization Interfaces — Computer-supported coopera- 
tive work, Organizational design, Theory and models, Web- 
based interaction; 1.2.1 [Computing Methodologies] : Ap- 
plications and Expert Systems — Games 

General Terms 

Design, Experimentation, Human Factors 

Keywords 

Games and infotainment 



1. INTRODUCTION 

Multiplayer Online Games (MOGs) are by now a market 
and a social phenomenon. They are also capturing the at- 
tention both of academia and industry because of the many 
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common problems, related to their distributed nature, which 
can be approached and solved using enterprise solutions and 
novel techniques. 

MOGs can be classified in several ways, for instance con- 
sidering the system environment, the number of players, by 
the action being in real-time or by turns, or just by game 
genres. Actually, the most attractive MOGs family is the 
one called Massively Multiplayer Online Games (MMOGs), 
which differs from other MOGs in that they are played over 
the Internet by thousands of players interacting in the same 
persistent real-time world. 

Depending on the game genre, we classify MMOGs in 
categories, i.e. MMORPGs (Role Play), MMOFPS (First- 
Person Shooter), MMOSGs (Strategic), and so on. Depend- 
ing on the game platform we have another taxonomy, clas- 
sifying MMMOGs as playable on mobile devices, and BB- 
MMOGs (Browser based), differing from standard ones, e.g. 
games for PC or console, because they are accessible from 
the World Wide Web without any client-side installation. 

The aim of this work is to introduce Living City, a BB- 
MMOG we designed and implemented at the University of 
Messina, focusing on some interesting aspects that we en- 
countered during these steps and analyzing results obtained 
after almost a year of public testing. The first Living City 
FJ public beta version has been played by almost ten thou- 
sand users registered during this period, providing us a good 
amount of data useful to extract relevant information about 
users activity and practices, especially on the social interac- 
tion among them, and tips on game balancing and optimiz- 
ing the user interface. 

The paper is organized as follows: in Section 2 we con- 
sider the related work on MMOGs, in particular regarding 
Browser-based games. Sections 3 and 4 cover the design and 
the development of the Living City project, detailing some 
interesting aspects of the architecture and the business logic 
of the game. Section 5 presents an in-depth analysis on the 
user activity and some final considerations of social interac- 
tions among players. 

2. RELATED WORK 

The fast growth and the attention MMOGs captured is 
witnessed by several valid works on the subject; they focus 
on architectural issues (e.g distribution techniques [16], load 



balancing 11 , persistence [19], etc.) and Software Engi- 



neering, e.g. usability [I], performances measurement [8], 



services platform 13 
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In 2005 Yan and Randell [17] provided a useful taxonomy 
of cheating in online games, covering fifteen cheating tech- 
niques and approaches and their relative countermeasures. 
A year later a remarkable game suggestion from Almeida 
and Gomes [2] introduced some interesting ideas on the BB- 
MMOGs development. Niso [12] provided an exhaustive re- 
port of the production life cycle of a BBMMOG. In the same 
year Ferrara [6], in his M.Sc. dissertation, started the design 
of Living City. Our ultimate goal then is to give our con- 
tribution to cover the gap between academic research and 
game industry in the design and implementation of Living 
City. 

3. GAME DESIGN 
3.1 Focus 

The primary idea was to focus the game concept on the 
players collaboration, providing motivations to cooperate in 
order to reach personal in-game objectives with the sup- 
port of the community of other players, or, in fact, making 
harder or impossible to complete some tasks without coop- 
eration and collaboration. This because we analyzed the ac- 
tual game design trends, pointing out that, despite the fact 
that many commercial BBMMOGs appear to be collabora- 
tive, actually almost each gameplay discourages cooperation 
among players, focusing on competitive aspects of the game 
and relying on the game addiction. 

Common BBMMOGs genres are Sports, Role Playing, 
Strategy and Simulation. For each of these genres there 
are dozens of examples, and also hybridization were devel- 
oped, for instance games with both Role Play and Strategic 
features, etc. Furthermore, Sports BBMMOGs generally 
include both management and simulation aspects. These 
three segments in most cases imply player competition. Ac- 
tually the last genre, simulation, allows both collaborative 
and competitive game styles. We chose the simulation seg- 
ment to start our analysis, designing an innovative game 
concept. 

3.1.1 An Overview on BBMMOGs Features 

BBMMOGs can be classified according to graphical fea- 
tures, e.g. animated graphics, graphical user interface, etc. 
Some of them are usually based on Adobe Flash[^]or Java[^] 
and are similar to off-the-shelf MMOGs. Others are based 
on HTML pages, being developed like usual Web applica- 
tions. The former category of games implies a huge amount 
of work on graphical compartment and scripting, the lat- 
ter requires a better design, in particular on database and 
interface. Both show common advantages: 

• Availability 

• Business Model 

• Accessibility 

• Architectural Requirements 

• Performances 

• Limited Development Efforts 

2 http: / /www. adobe. com 
3 http : / /sun . j ava. com 



The availability represents a great incentive for players 
because they have a huge number of games, almost freely 
playable, and the freedom of choosing the most suitable for 
their expectations: indeed, at difference with common off- 
the-shelf games, BBMMOGs are free-of-charge, except for 
some features, usually presented as premium ones, which 
sometimes give a couple of advantages in the game to pay- 
ing players, and/or are represented by special items with 
some singular powers. In these games the business model is 
also built around the advertising, which often becomes the 
greater economic income for developers. Another advantage 
is that the game itself can be advertised on the same adver- 
tising channels, specifically oriented to the game market, so 
applying strategies to attract the maximum possible number 
of paying players. 

Regarding architectural aspects, there are a couple of ad- 
vantages both for players and developers, related to the Web 
nature of the product: the accessibility is global because BB- 
MMOGs cut off the distribution channels of physical prod- 
ucts, completely relying on Internet websites; this is usually 
an advantage also in comparison with off-the-shelf MMOGs, 
which are usually sold in shops, like any other stand-alone 
game. Consequently, architectural requirements are really 
low, indeed any hardware configuration that can host a Web 
application server fits good the work. A quantitative and 
qualitative dimension of the server configuration, related to 
expected traffic and quality of service we must ensure, should 
be designed and provided by developers: performances will 
be commensurate to the strength of this architecture, but, 
equal investment, are much more effective and solid w.r.t. 
other architectures, designed with the same budget, to run 
standard MMOGs. Last but not least, the limited effort 
to develop BBMMOGs represents a good reason to study 
this field of application in academia, and represents a huge 
advantage, especially in industry, enabling small teams to 
start-up in a market segment, so rapidly developing appre- 
ciated products. 

3.1.2 Game concept 

Living City is a simulation game designed to be collabora- 
tive and socialization oriented: the main aim for players is to 
manage and administrate a virtual city, embodying the role 
of the Mayor, including staff, economic, construction and in- 
vestment management tasks, services administration, busi- 
ness decision-making, etc. The game concept is widely in- 
spired by the 'SimCity' computer games series, created and 
first developed by Will Wright in 1989, with major changes 
regarding the game orientation to multiplayer goals: Living 
City is designed to make possible to manage collaborative 
tasks like services providing, building permits, licenses re- 
leasing, procurements proclaiming, etc. All these aspects 
of the game require cooperation among players and cannot 
be completed playing alone. Notwithstanding it is possible 
to slowly advance in the game also taking not care of some 
of these points. Cooperation is a key evaluation criterion 
for algorithms deciding which cities should grow faster than 
others, which should acquire more relevance, etc. 

3.2 Structure of the Game 

Living City is structured in the following macro areas: 

• Mayor and Staff; 

• City and Buildings, and 



• Management. 

There are also additional, although not strictly game- 
related, areas regarding community of players, m-game tools, 
and game guide. We will cover all these aspects of design 
and development of the simulation. 

3. 2. 1 Mayor and Staff 

In this first macro area, the player can access different sec- 
tions to manage and monitor aspects regarding his game pro- 
file and, moreover, statistics, performances and productivity 
of own staff. A priority, in the starting phase of the game, 
is recruitment: the Mayor has to cover some relevant posi- 
tions (e.g. the Deputy Mayor, Public Relationships, Human 
Resources, Technicals and Engineers, Administrators, etc.) 
employing NPCs (Non-Player Characters); their activity is 
controlled by the system and is fundamental for completing 
some tasks (e.g. managing the provision of services, issuing 
calls for procurements, etc.), but there are limitations on 
recruitment (e.g. a maximum defined number of employ- 
ees in each role, considering hiring/firing effects, etc.). The 
right choices will imply better staff performances, players 
have tools (e.g. each NPC has a fictitious blog that auto- 
matically and dynamically reports his/her thoughts about 
the assigned tasks, a page with statistics and graphs to ana- 
lyze performances of employees, etc.) and indicators (e.g. a 
rating scale for public parameters) to monitor the working 
group. 

There are also several activity configurations to tune. Some 
of them help the player to tune attitudes and behaviors in 
his/her staff even outside the working hours, and, most im- 
portantly, working tasks they have to complete, depending 
on their position. All these variables and results are cal- 
culated through public and hidden parameters related to 
employees. Each NPC has got common attributes (i.e. will- 
ingness to work, ability to work in team, concentration, in- 
tuition, motivation, etc.), and some expertise, related to his 
role: better employees cost much to the administration but 
ensure better performances and productivity. 

Players have to balance requirements with costs and the 
hidden optimization function is dynamically generated by 
the system, considering more than 50 variables and param- 
eters related to the actual condition of the city, degree of 
development, needs, etc: this ensures that there is no sim- 
ple solution to the problem of the recruitment or a standard 
setup of the staff which fits well in any situation. One of the 
game challenges is to find a good staff configuration over the 
time. 

3.2.2 City and Buildings 

The second macro-area allows players to develop struc- 
tural aspects of the city: after the registration each user re- 
ceives a virtual plot of land to start his administrative work 
of building construction. Living City, as the name suggests, 
is a full real-time online game: this means, mainly, that 
each in-game action implies a real time request, expressed 
in real minutes, hours or even days, depending on the degree 
of complexity of the task. Starting from the lowest levels, 
i.e. village, town, small city, and so on, up to metropolis, 
the level of the plot of land grows unlocking more and more 
new options and tasks over the time, through eight levels of 
increasing difficulty. 

The system to develop buildings is complex, so we schema- 
tized it as follows: there are seven categories of buildings, 



each category has got several sub-categories. Each player 
can build at the same time only one structure for each cat- 
egory, so the system encourages users to follow a planning 
strategy to maximize development. This is the classification 
of buildings in Living City: 

• Free Areas (19 total buildings), i.e. Residential, Com- 
mercial, Industrial, etc; 

• Transport (18 total buildings), i.e. Transportation, 
Public places, etc; 

• Services (16 total buildings), i.e. Power and Water 
supply, Garbage collection, etc; 

• Institutional Buildings (17 total buildings), i.e. Insti- 
tutions, Police, Firefighters, Army, etc; 

• Public Facilities (19 total buildings), i.e. Education, 
Health-care, Worship 

• Tourism and Others (18 total buildings), i.e. Accom- 
modation, Various 

• External Buildings (40 total buildings), i.e. Commer- 
cial, Industrial, Tourism 

Each point is self-explanatory except the latter: external 
buildings comprises all the structures which can be placed 
in plots of land belonging to other players after acquiring 
a building permit, for instance winning a procurement for 
providing a particular service. Living City allows up to 147 
total buildings, a huge number if compared to other manage- 
ment games which count a couple of dozens of possibilities, 
some mutually esclusive (e.g. Ogame Q Travian Q etc.). 
Structures require virtual money and actual time to be de- 
veloped: for each level of development of the city, the player 
can build a couple of structures for each category. Buildings 
themselves grow by levels, from 1 to 12: each upgrade re- 
quires more time and money, usually less than the construc- 
tion from scratch, and grants some small bonuses. Indeed, 
reaching the cap level of a building usually gives the most 
useful bonus relating to the category of the building itself. 
There are also services provided by buildings. We will cover 
this aspect in next sub-section. 

3.2.3 Management 

The management macro-area is the core of the simulation: 
players have to tackle economic problems and a wise man- 
agement of funds is central. There are many notable sub- 
sections: resources management allows the player to estab- 
lish how much money allocate to specific services provided 
to virtual citizens (usually called sims), to allocate funds to 
services maintenance, to tax collection, etc. All these pa- 
rameters (in addition to many others) are reflected on the 
virtual quality of life in the city, influencing aspects like pop- 
ulation distribution, law enforcement, welfare, health-care, 
employment, pollution and so on. 

The degree of simulation is high and this implies that 
users should take advantage of some powerful tools like the 
economic framework and the projections instrument: the 
former summarizes all economic aspects of simulation, in- 
cluding income (i.e. income taxes, earnings from provided 

4 http:/ /www. ogame. org 
5 http:/ /www. travian. com 



services, etc.) and costs sustained (i.e. utilities and services 
costs, etc.), payable and receivable interest, and so on, of 
the current and the past week. The latter is a dynamic real- 
time overview of the statistical data concerning the virtual 
quality of life. Each decision (e.g. modifications of config- 
urations of resources, in-game actions, etc.) taken by the 
Mayor is timely reflected on the data projections, and all 
values related to the virtual quality of life tend to these pro- 
jections. The player can thus get a feeling on the evolution 
of the game, and try to pursue wise decisions. 

There are two other gameplay aspects: licenses and pro- 
vided services. Each plot of land can ensure, depending 
on the level, a growing number of free slots; these can be 
licensed to other Mayors, in which can be built external 
buildings, useful to provide services required by the city. 
The development of such structures allows to provide spe- 
cific services related to the category of the building, so there 
are services related to utilities, supplies (i.e. power and 
water supply), transportation, tourism, etc. Players ac- 
quire building rights for external slots by winning a pro- 
curement. Likewise, the same players, by issuing calls for 
procurements, allow others to provide them services: this 
system ensures a reciprocal benefit to cities active in the 
licenses-procurements market. There are sections with tools 
useful to monitor procurements, both for issuing a call for 
new ones and to compete in existing procurements called 
by other Mayors. This play aspect is the core of the col- 
laborative and cooperative simulation and is maintained by 
three mechanisms (i.e., bid auctions, direct offers and fixed 
cost offers) to ensure that players come to an agreement in 
different forms of transaction. 

3.2.4 Tools, Community and Game Guide 

The last macro-area comprises three sections: tools, com- 
munity and game guide. We are not focusing on the former 
as it presents standard elements, like a search tool, a news 
page, a messaging system, etc. 

Much more innovative is the community section, including 
some key aspects of the social network phenomenon: each 
player can create a personal profile including information, 
share elements with others and so on, contributing in creat- 
ing a solid community of users. Players can also rely on the 
in-game forum, embedded in the same platform, which per- 
mits the creation of links between discussion threads, per- 
sonal and game profiles. The forum, for instance, allows 
players to integrate projections, statistics, graphs, etc. in 
their posts, to share game information, advices and tips. 
The community section presents pages for top rankings, di- 
vided by categories of ranking (fame, virtual quality of life, 
richness, number of buildings, etc.). Another innovative as- 
pect introduced in Living City is the embedded game guide: 
thanks to the Web-based nature of the game, we developed 
guide pages linked to game sections, and created macros, 
coded in JavaScript, that perform useful tasks for players 
(e.g. players can be warned when a building task is com- 
pleted by a pop-up message, etc.). The main idea was in- 
spired by the work of Kletsch and Volk [9] who integrated 
AJAX if] in the engine of a BBMMOG. 

3.3 Game Balance 

The key to develop an enjoying game is balance: an im- 
portant amount of time during the Living City design and 
testing phases was spent studying and fixing formulas and 



algorithms which manage consumable entities, like money, 
and real-time aspects, like the passing of time. Players' feed- 
back were fundamental to understand problems and to fix 
them, in particular those related to the impossibility of exe- 
cuting some actions while respecting economic and temporal 
limits imposed by some unbalanced functions. One of the 
most interesting challenges we faced was to balance the time 
a player should spend to proceed in the game: this task is 
not trivial because we had to find solutions that do not favor 
avid players who were going to spend hours playing, but, at 
the same time, that reward long time playing users, bene- 
fiting the long planning game style instead of the addiction 
game style. At the same time, balancing money earning and, 
generally, flow of money was pursued. 

3.3.1 Time Balancing 

We studied the real-time intervals required to build struc- 
tures, with a recursive exponential function in order to com- 
pute the amount of required time needed for each stage of 
construction and improvement of buildings: 

RequiredTimeAtStage(x) — RequiredTimeAtStage(x—l) a 

where we empirically assumed f.04 < a < 1.06 and Re- 
quiredTimeAtStage(l ) being the required time to build from 
scratch. 

We carefully compiled a table of all required build from 
scratch times for the 147 structures included in Living City, 
ranging from 90 to 3000 seconds, depending on the com- 
plexity of the building and the level required to build it. 
We obtained 29 different required times, grouped in 5 time 
classes (referred to buildings with similar required times to 
build from scratch) reported in Table 1. 
The value of a is in inverse proportionality to time classes, 



Class 


Required Time 


a 


I 


90 < RequiredTimeAtStage(l) < 300 


1.06 


II 


300 < RequiredTimeAtStage(l) < 600 


1.055 


III 


600 < RequiredTimeAtStage(l) < 1200 


1.05 


IV 


1200 < RequiredTimeAtStage(l) < 1800 


1.045 


V 


RequiredTimeAtStage(l) > 1800 


1.04 



Table 1: Time Classes and Required Times 



since we realized that it was really hard (to nearly impos- 
sible) to complete all the 12 stages of buildings with high 
RequiredTimeAtStage(l), because of the exponential aspect. 

In Figure [I] the required time is expressed as a function 
of each of the 12 stages of the building development. Each 
line represents one of the 29 RequiredTimeAtStage( 1 ) values, 
and grows exponentially in relation to the development stage 
of buildings. This algorithm defines a smooth exponential 
function and appears to be the solution which fits our needs, 
in term of time balancing. 

It is also interesting to analyze the reverse plot: putting 
the 29 RequiredTimeAtStage(l) values on the abscissa, the 
12 lines represent the development stages of buildings (Fig- 
ure We observe that lines are not smooth, rather we 
have an exponential step function, each of the 4 steps re- 
flecting how the variation of a over [1.04, 1.06] affects the 
function, as a consequence of the transition among time 
classes. The direct consequence of this phenomenon is that, 
some buildings having a low RequiredTimeAtStage(l) in an 
higher time class, at advanced stages of development require 
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Figure 1: RequiredTimeAtStage(x) as a function of 
stages 



less time than those on lower time class but with high Re- 
quiredTimeAtStage(l), within the time class itself. This is 
so because of the inverse proportionality of a relative to 
growing time classes. For example, a building requiring 540 
seconds (a = 1.055) for completing stage 1 of construction, 
will take more than 80000 seconds for upgrading from stage 
11 to 12. On the opposite, a building requiring 600 sec- 
onds (a = 1.05) takes less than 60000 seconds for the same 
upgrade. 
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Figure 2: RequiredTimeAtStage(x) as a function of 
building completion times 

It is also interesting to compute the lower bound for con- 
structing and improving all buildings in the game up to the 
cap level: 



MinTime = RequiredTimeAtStage(xk) 

k=l x=l 

= 27978980, 96 sec. = 7771, 93 hours ~ 324 days, 
where k denotes the k — th building. 
3.3.2 Budget Balancing 



After fixing the function for time balancing, we studied a 
similar function to balance cash flows in building construc- 
tion and improvement process: 

BuildingCostAtStage(x) — ft- BuildingC'ostAtStage(x-l) 

where we empirically assumed 0.10 < /3 < 0.15 and Build- 
ingCostAtStage(l) being the required money to build from 
scratch. 

This is a linear-growth function that has been found to 
be more realistic. We established all the 147 build from 
scratch required parameters, in the 2,000.00 to 387,500.00 
Euro range, relating to the degree of complexity and the 
required level of each building. We thus obtained exactly 
100 different costs; we preferred not to create cost classes, 
rather we calculated the /3 value, once again in inverse pro- 
portionality to the cost, normalizing the interval [2,000.00, 
387,500.00] to the interval [0.10, 0.15]: 



£ = 0.15 



BuildingCostAtStage(l) ■ (0.15 - 0.10) 
(387,500.00 - 2,000.00) 



This function fits our needs: each upgrading stage costs 
much less than building from scratch. On the opposite the 
full process of improvement from stage 2 to 12 costs more 
than the BuildingCostAtStage(l). 



S — BuildingCostAtStage{x) 

It is easy to show that, with ft £ [0.10, 0.15], we have the 
following boundaries: 
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Figure 3: 



BuildingC ostAtStage(l) 



and S functions 



As can be seen in the left plot represented in Figure [3] 



the 



function decreases in inverse pro- 



BuildingCostAtStage(l) 

portionality to the growth of BuildingCostAtStage(l) costs. 
We have a linear decrease of money required for improving 
buildings. On the right plot in Figure [3J S is plotted as 
a function of costs: as can be seen it reflects the expected 
summation function behaviour and also here is possible to 
see how values are contained in the interval ]|,4[. At the 
boundaries we have: 



/(2000) = 2000 • 3.64 = 7280 

/(387500) = 387500 ■ 1.68 = 651000 

The linear behaviour of the BuildingCostAtStage(x) func- 
tion is more clearly shown in Figure [4] where lines represent 



the BuildingCostAtStage(3 . . . 12), related to the Building- 
Cost AtStage(2), represented on the abscissa: it can be seen 
that the ratio of the two axes is comprised in the ]§,4[ in- 
terval. 
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Figure 4: BuildingCostAtStage(3. . . 12) as a func- 
tion of BuildingCostAtStage(2) 



4. THE UNDERLYING BUSINESS LOGIC 

MMOGs are fundamentally complex client-server appli- 
cations; BBMMOGs, in particular, exploit the three-tier ar- 
chitecture [H] as a viable design pattern which fits well archi- 
tectural requirements. We focus on the business logic tier, 
exploring some interesting aspects of the logic of Living City, 
e.g. the simulation of time passing (earlier explained), the 
avoidance of cheating, the bug exploiting in the game and 
the problem of handling concurrency. 

Differently from classic MMOGs, where there are some 
servers and a client that needs to be installed, in BBMMOGs 
there is a sort of inversion of the point of view. In the former, 
each client is connected to a central single world, to which, 
for instance, also administrators could connect and monitor 
players; in the latter, the instance of the world is replicated 
in the Web browser of each player, which makes a central 
control checking impossible, and introduces also updating 
and persistence problems. 

4.1 Cheating Avoidance 

In accord to Yan and Randell's classification [17], we ap- 
plied cheating avoidance criteria on a large set of possible 
vulnerabilities and failures. All solutions have been designed 
to ensure an high standard of game fairness as a conse- 
quence. We implemented a series of JavaScript functions, 
that connect the user interface to the logic layer. At DBMS 
level, referential integrity constraints and checks have also 
been implemented. 

Some cheating typologies do not apply to Living City be- 
cause of its intrinsic nature. This is the case of exploiting 
misplaced trust and modifying client infrastructure. It can 
not be applied since there is no any client executable pro- 
gram, replaced by the Web user interface. Some others are 
excluded because of the design of Living City, e.g. exploiting 
machine intelligence, as there are no objects governed by an 
AI engine, all the playing characters are human. Also, cheat- 
ing related to internal misuse is avoided as administrators 



cannot own game accounts. 

Apart from Social-Engineering cheating, whose purpose is 
to steal information, e.g. account user-name and password of 
other players, which are pretty hard to prevent, we focused 
on some possible vulnerabilities of the system, i.e., cheat- 
ing by abusing the game procedures and exploiting bugs. 
Two notable examples are illustrated in some detail in the 
following sub-sections. 

4.1.1 SQL Injection Avoidance 

SQL Injection [5] is a well-known class of techniques, fre- 
quently used in BBMMOGs (and, generally, in Web appli- 
cations) , exploiting system vulnerabilities of lack of control 
and filtering of the input: its aim is the insertion of destruc- 
tive or spoiling SQL commands through a smart tampering 
of natural SQL commands sent from the client (the Web user 
interface), thus directly compromising the database layer in- 
tegrity. Living City has been designed with shrewdness: all 
information that could be retrieved from the game interfaces 
come from database views, i.e., virtual data structures built 
as a result of queries on tables, multiple table join, aggregat- 
ing data, etc., with the aim of hiding structural information 
to users. It could be argued that could be not enough: de- 
spite views, it could be still possible to attack the database 
layer through blind SQL injection techniques [l4], flooding 
the system with automatic generated SQL commands that 
attempt to find a vulnerability also without any response 
from the system itself. These blind techniques are poten- 
tially dangerous as targeted SQL attacks, so a double secu- 
rity check was designed. All SQL commands implemented in 
the game are parameterized statements [15] . So it is possi- 
ble to change only values of parameters but not structure of 
statement, thus ensuring an high standard of security, since 
all parameters are processed by an SQL engine designed 
specifically to prevent these kind of tampering. Moreover, 
all incoming SQL queries from dangerous entry-points (i.e. 
free text-boxes) are pre-processed looking for destructive or 
spoilage commands (i.e. drop tables, selecting from master 
database, altering tables, modifying users, etc.), prevent- 
ing, de facto, that information could be extracted or deleted 
through tampering queries. 

4.1.2 Simultaneously Buildings Avoidance 
Another important difference among standard MMOGs 

and BBMMOGs is related to inner concurrency: obviously, 
a player may not open two clients and log in the same 
world with the same account in a well designed MMOG. 
Vice versa, in a BBMMOG players could execute multiple 
operations by simply opening multiple browser tabs. In- 
deed, a conceptual gameplay limit of Living City is that a 
player cannot simultaneously build two structures belonging 
to the same category: without any check it could be possi- 
ble for a user to open multiple tabs on the same category 
page buildings, thus starting different, albeit theoretically 
mutually-exclusive, tasks. 

In order to avoid this type of cheating, we implemented a 
double check that uses AJAX, business logic and database 
constraints. It works as follows. Each time a player exe- 
cutes a building task, a JavaScript function asynchronously 
calls a check procedure aimed at verifying the value of a 
Boolean static variable related to the building category: a 
true value means that another building task of the same 
category is currently running and this information is noti- 



fied to the player. It could happen that a skilled attacker 
could launch multiple tasks, from multiple pages, exactly at 
the same moment, so we also designed integrity constraints 
directly at the database level. For instance, the timestamp 
of each building task is checked in order to verify the le- 
gitimacy of any other task in the same category during the 
same game session. 

4.2 Handling Concurrency 

A similar approach is used to handle outer concurrency- 
there are elements in the game, like fixed price procure- 
ments, which could be simultaneously awarded by two or 
more players (or, by an extreme, by the same player from dif- 
ferent instances of the Web browser). Also the recruitment 
step is very sensitive: unemployed staff members (regard- 
less of whether they have ever been employed or they have 
been fired or their Mayor left the game and his account was 
deleted by the system) can be hired by Mayors searching 
a common marketplace; all these cooperative/competitive 
gameplay situations require an accurate handling of concur- 
rency. We called these phenomena outer concurrency be- 
cause of the interaction among different players. As a con- 
sequence of its intrinsic nature of Web application, in Living 
City all information that must be shared among players, are 
published on HTML pages, which are dynamically generated 
at the time of the user request. This implies that data could 
become obsolete while a player is reading them, since players 
in real-time concur for the same resources. 

We approached and solved this problem by exploiting AJAX 
asynchronous updating of pages. Database locking features 
at the DBMS tier was also adopted, in order to save the 
referential integrity when AJAX is not enough. This situ- 
ation causes a relevant amount of transactions that are to 
be executed in a relatively short time interval. In order 
to assure good performances, we carefully optimized all the 
real-time checking algorithms which handle the concurrency 
of actions. Fortunately all these operations are relatively 
simple to implement, since the only variable to be checked 
is the availability of the requested resource. 

5. RESULTS AND FINAL REMARKS 

The beta-testing period lasted almost a year: during this 
time, only a couple of players reached the highest ranking 
in all possible tasks and developed all structures, thus com- 
pleting the game. Their achievement confirms that at least 
11 months of gaming are needed to reach the cap level of 
Living City: indeed most players reached medium- high lev- 
els with 6-8 months of moderate playing. A good number of 
players demonstrated a notable management capability and 
a profitable ability to maximize tasks and activities. For 
instance, it is not a trivial task to optimize the develop- 
ment time of buildings, because players can build only one 
structure for each category at the same time. Interestingly, 
analogous considerations are found in Allegra et al. [I] work 
on learning. 

5.1 User activity Analysis 

We studied results analyzing log data related to 11 months 
(from January 7th to December 7th, 2009) of activity. Dur- 
ing this period Living City had 9775 registered and active 
players and almost 165000 visits; this means that the game 
had 6% average conversion of visitors into new players each 
day. Moreover 29% of the traffic each day came from new 



visitors (i.e., 71% of returning visitors are registered play- 
ers). The server displayed over 3 million pages to players, 
with an average of 16.7 pages per visit. We estimated that 
the number of average visits per day from the same player 
was 3.06, with an average duration of 10.15 minutes per 
visit. We also have statistics about the game activity: 

• 192310 buildings (avg. 19.67 building/player) 

• 75627 calls for procurements (avg. 7.74/player) 

• 8919 offers for procurements (avg. 0.9/player) 

• 11488 services provided (avg. 1.17/player) 

• 120722 staff members employed (avg. 12.35/player) 

• 7327 capital investments (avg. 0.75/player) 

We also gathered some data about social activities: play- 
ers exchanged 2662 personal messages during this period 
and discussed a lot on the in-game forum; they created 689 
threads, with 3363 total posts (almost 5 posts/thread on av- 
erage). The percentage of threads without any reply is less 
than 6%. 

5.1.1 Considerations 

It is interesting to analyze the time spent playing the 
game. In Figurc[5]we plotted the average duration per visit. 
A similar behaviour should result from the plot of the history 
of the time spent on the game by a single player. The start- 
up of the game requires much time per visit (almost half 
an hour for each game session), as operations and tasks are 
more frequent and last less time. Higher levels require 10-15 
minutes-per-game sessions. Considering that each player in 
average starts 3 game sessions each day, the time spent is 
less than two hours a day: the game makes players involved 
but should not cause addiction. 
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Figure 5: Average playing time 

Figure|6]shows the distribution of time percentage for each 
level of the game. There is an important contribution from 
new players. Physiologically, some of them will leave the 
game in the future. At the same time, almost a third of the 
users who started to play reached the cap level (indeed many 
features are unlocked at level eight, so the game is anything 
but completed). 

Analyzing in-game activities, we concluded that we must 
improve some features, like the procurement and the invest- 
ment systems: although these gameplay aspects are mas- 
sively introduced at later stages game, only a relatively small 
number of players took advantage of them (in fact the aver- 
age values of this time are not really significant, because the 
most important number of procurement offers and capital 
investment came from only a couple hundreds of players). 

5.2 Social Interaction 
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Figure 6: Player distribution over levels 

5.2. 1 Social And Psychological Aspects 

Klimmt et al. [To] studies opened a new perspective on 
the MMOGs design: they found that 'competition, in con- 
trast, seems to be less important for browser gamers than 
for users of other game types '. This result is pretty impor- 
tant as it introduces an unexpected orientation to cooper- 
ative gameplay which is usually nonexistent in MMOFPS 
and low in MMORPGs. Massive collaborative tasks have 
been designed to be the core of evolution in the game, thus 
making impossible to reach the cap level of the game playing 
alone. Our experience with Living City confirms that in BB- 
MMOG players like cooperation, and do not dislike collabo- 
ration together with competition to tackle game challenges 
(e.g. concurring for fame and climbing rankings). Yee [18] 
submitted a list of questions about motivations of playing 
MMOGs to a sample of 3000 regular players, and discovered 
how aspects of achievement, social and immersion compo- 
nents interact and determine the in-game behaviour of play- 
ers. Socializing, relationship-building and team-working ap- 
pears to be relevant and as important as other achievements, 
usually considered more influencing, like advancing in the 
game, role-playing and competition. We can say that both 
Klimmt's and Yee's expectations and results are empirically 
confirmed through the approval by players of gameplay and 
collaborative dynamics of Living City. 
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